Q. 채용 과제를 제출할 때 완성하지 못한 부분은 어떻게 설명하나요?

답변 5

• q

  qeasdasdqweqe한영회계법인

  코부장 ∙ 채택률 86% ∙

  학교

  일치

  ---

  채택된 답변

  완성하지 못한 부분을 숨기기보다는 현재 진행 상황과 이유를 명확하게 설명하는 게 좋아요. 예를 들어 '핵심 기능은 구현했으나 시간 제약으로 예외 처리 부분은 완료하지 못했습니다. 추가 시간이 주어진다면 해당 부분을 우선 보완하겠습니다'라고 작성할 수 있어요. 다만 미완성 상태 자체가 평가에 영향을 줄 수 있으니, 제출 전에는 필수 요구사항부터 최대한 완성하는 것이 중요합니다!

  ---
• 

  채택스포스코

  코부사장 ∙ 채택률 69%

  ---

  채택된 답변

  안녕하세요. 멘티님. 반갑습니다. 채용 과제에서 완성하지 못한 부분이 있다면 숨기기보다 분명하게 적는 편이 훨씬 좋습니다. 다만 미완성이라고만 쓰지 마시고 어떤 요구를 먼저 끝냈고 어떤 부분을 뒤로 미뤘는지 기준을 함께 보여주시면 됩니다. 예를 들면 핵심 기능 구현을 우선했고 검증이나 부가 기능은 시간상 제외했다는 식으로 정리하면 채용 담당자는 지원자의 판단 기준을 자연스럽게 보게 됩니다. 이때 중요한 것은 변명처럼 보이지 않게 현재 상태를 사실대로 적고 이후 보완 방향을 짧게 붙이는 것입니다. 평가하는 입장에서는 완성도만 보는 것이 아니라 시간 안에 무엇을 먼저 처리했는지 판단력이 보이길 원합니다. 그래서 제출 자료에는 미완성 항목과 생략 사유 그리고 다음 보완 순서를 간단히 넣는 것이 좋습니다. 특히 왜 그 순서로 진행했는지 적어두면 실무에서도 우선순위를 세울 줄 아는 지원자로 보이기 쉽습니다. 다만 지나치게 길게 쓰기보다는 핵심만 담아서 읽는 사람이 바로 이해할 수 있게 정리해보시구요. 모쪼록 도움이 되셨다면 채택부탁드립니다. 감사합니다.

  ---
• 라

  라면두개가능한영회계법인

  코부장 ∙ 채택률 99% ∙

  학교

  일치

  ---

  채택된 답변

  완성하지 못한 부분을 숨기기보다는 현재까지 수행한 내용과 미완성 부분을 명확하게 구분해 설명하는 것이 좋습니다. 예를 들어 "핵심 기능은 구현했지만, 시간 제약으로 일부 예외 처리와 사용자 편의성 개선은 완료하지 못했습니다"라고 작성할 수 있습니다. 여기에 미완성 원인과 향후 개선 계획을 덧붙이면 문제 해결 과정과 업무 우선순위를 판단하는 능력을 보여줄 수 있습니다. 다만 과제 제출 지침과 필수 요구사항을 먼저 확인해야 합니다.

  ---
• 

  취뽀도우미입니다삼성SDS

  코상무 ∙ 채택률 97%

  ---

  채택된 답변

  시간이 제한된 채용 과제에서 핵심 기능을 구현하고 일부 부가 기능이나 검증을 마치지 못했다면 제출 자료에 그 내용을 솔직하고 명확하게 작성하는 것이 좋습니다. 결과물을 평가하는 입장에서는 모든 것을 완벽하게 만든 지원자보다 주어진 시간 안에서 어떤 기능을 우선순위로 두고 개발했는지 그 판단 과정을 이해하는 것이 훨씬 중요합니다. 따라서 제출물과 함께 동봉하는 문서나 별도의 설명란에 현재 완성하지 못한 부분이 무엇인지 구체적으로 밝히고, 왜 그 기능을 미완성으로 남겨두었는지 타당한 이유를 적어주시는 것을 추천합니다. 예를 들어 시간 부족으로 인해 예외 처리나 단위 테스트를 충분히 거치지 못했다면 이를 솔직하게 언급하고, 실무에 합류했을 때 어떤 순서와 방식으로 해당 부분을 보완할 것인지 구체적인 개선 계획을 덧붙이는 것이 좋습니다. 변명이나 핑계처럼 보이기보다는 자신의 작업 방식을 객관적으로 메타인지하고 있으며, 리소스 관리 능력이 있음을 보여주는 방향으로 작성한다면 평가자에게 오히려 책임감 있고 프로페셔널한 인상을 남길 수 있습니다.

  ---
• P

  PRO액티브현대트랜시스

  코부사장 ∙ 채택률 100%

  ---

  네, 적으시는 것이 좋습니다. 평가하는 입장에서는 완성도 못지않게, 지원자가 제한된 시간에서 무엇을 먼저 했고 무엇을 남겼는지를 보기 때문입니다. 미완성 부분을 숨기면 몰라서 놓친 것인지 알고도 미룬 것인지 구분되지 않아 오히려 불리할 수 있습니다. 반대로 스스로 알고 있었고 이유가 분명하다면 판단력의 증거가 됩니다. 설명은 짧고 구체적으로 쓰시길 권합니다. 먼저 핵심 요구사항을 어떤 범위까지 구현했고 어떻게 동작을 확인했는지 밝히세요. 그다음 완성하지 못한 부분을 있는 그대로 적되, 시간이 부족했다는 말로 끝내지 말고 왜 그 부분을 뒤로 미뤘는지 우선순위의 기준을 한두 문장으로 설명합니다. 예를 들어 핵심 흐름의 안정성을 부가 기능보다 먼저 확보했고, 검증은 가장 위험한 경로부터 했다는 식입니다. 이어서 시간이 더 있었다면 어떤 순서로 보완했을지, 그리고 그렇게 판단한 이유를 적으면 사고 과정이 선명해집니다. 검증을 못 한 부분은 확인되지 않은 상태임을 분명히 밝히고, 어떤 위험이 남는지도 함께 쓰시면 신뢰가 높아집니다. 반대로 피하실 것은 변명처럼 길게 늘어놓는 것, 미완성인데 완성된 것처럼 쓰는 것, 그리고 설명이 코드나 결과물보다 앞서는 것입니다. 이 내용은 README 하단이나 제출 문서의 한 항목 정도로 간결하게 두시고, 결과물 자체가 요구사항을 충실히 충족하도록 하는 것이 우선입니다. 한계를 정직하게 밝히고 다음 단계를 구체적으로 제시하는 태도가 평가자에게 가장 좋은 인상을 줍니다.

  ---